\subsection{Security Rules (SR)}
\label{sec:security-rules}




Security requirements are specified in the form of security policies. Security policies regulate interactions between system users and resources. They include the following abstract basic entities:
\begin{itemize}
\item Roles: A role represents a set of system users or resources\footnote{We have chosen to abstract resources using roles to minimize the number of basic policy entities.}.
\item Actions: An action is an abstraction of how system users and resources interact, e.g. by means of a method call in the case of Java application.
\item Contexts: A context is an abstraction of a set of conditions on the system state. A context defines the application conditions of security rules.
\end{itemize}

Using these basic entities, security experts can specify coarse-grained and fine-grained Security Rules. Figure \ref{fig:rules} describes the Security Rules metamodel. A \texttt{SecurityRule} has an unique identifier \textsf{RuleId} (to allow further reference), an optional \textsf{subject} \textsf{Role}, an \texttt{Action}, and an \textsf{activation} \textsf{Context}. The following options confer additional flexibility and power to the rules: if not specified (denoted by \texttt{\_} in the concrete syntax), a role can be matched to any subject or target. 


\SAR allows security rules to be either permissions, prohibitions or obligations. A \textsf{SecurityRule} is also either \textsf{ActionBased} or \textsf{StateBased}. An \texttt{ActionBased} rule specifies a requirement on the available set of \texttt{Action}s and may have a \texttt{target} role on which the \texttt{Action} applies. Such a rule can be either a \textsf{Permission}, a \textsf{Prohibition}, or an \textsf{Obligation} that defines a \textsf{Violation} context, i.e. a deadline before which a subject has to take the obligation's action, otherwise the obligation is considered violated. A \texttt{StateBased} rule specifies a requirement on the application state rather than possible actions. Since permitting a state (i.e. such a state can be reached or not) is generally not useful, such rule is only either \textsf{ObligationS} or \textsf{ProhibitionS}, both defined with a \texttt{Violation}: they can actually be dual, meaning that prohibiting to reach a given state is equivalent to obligating not to reach this state. 

A \texttt{Context} specifies when a rule is active, or an obligation deadline, i.e. time when an active obligation is considered violated. It is defined as a boolean expression language that can either be a \texttt{TruthValue} (specified as an enumeration of the boolean values \texttt{true} and \textsf{false}, not represented in the metamodel), a \texttt{ContextId}, a \texttt{Delay}, or a combination of contexts by \texttt{Conjuction} (meaning that the context holds if both \texttt{operands} hold), by \texttt{Negation} (meaning that a context hold if its operand does not), or by \texttt{Interval} (denoted as \textsf{[lhr, rhs]} and meaning that a context hold since the left-hand side \texttt{lhs} hold until the right-hand side \texttt{rhs} does). A \texttt{ContextId} just defines a context \texttt{name} that will be precisely defined using a \texttt{DynamicBinding} (cf. Sec. \ref{sec:dynamic-binding}). A \texttt{Delay} defines a time period after which a context holds consequently to a security rule activation (e.g., \texttt{10m} means ten minutes). We refer the interested reader to \cite{Cuppens2003,Elrakaiby2011} for a more comprehensive presentation of our context language. 


We exemplify our security policy language by presenting the specification of the security requirements introduced in Section \ref{sec:MotivatingExample}. 

\medskip
\begin{scriptsize}
	\begin{sffamily}
\noindent
permission(r1, doctor, consult, file, fileIsPrivate \& fileOfPatientAssignedToDoctor).

\noindent
obligation(r2, doctor, submit, report, begining\_of\_month \& reportOfPatientAssignedToDoctor, delay(7d)).

\noindent
obligation(r3, doctor, submit, report, violation\_r2, delay(7d)).

\noindent
prohibition(r4, doctor, consult, file, violation\_r2 \& fileIsAdministrative).

\noindent
obligation(r5, doctor, delete, file, fileOfPatientAssignedToDoctor, delay(2y)).

\noindent
obligation(r6, doctor, create, file, fileIsEncrypted \& patientFileIsSensitive \& fileOfPatientAssignedToDoctor, delay(1m)).


\end{sffamily}
\end{scriptsize}

\medskip\noindent
These previous rules are expressed using policy concepts: we recognize the \emph{roles} \textsf{doctor}, \textsf{file}, \textsf{report}; the \emph{actions} \textsf{consult}, \textsf{submit}, \textsf{delete} and \textsf{create}, and the contexts \textsf{fileIsPrivate} and {fileOfPatientAssignedToDoctor}. At this stage, none of these concepts are connected to an implementation. We note the closeness of the textual syntax chosen to informal requirements. This First-Order Logic predicate representation of policies also correspond to the practice of security experts, who commonly use FOL \cite{Jajodia1997a,Kagal2003,Elrakaiby2011} for specifying policies.
 


In the rules above, \textsf{R1} and \textsf{R5} are \textsf{ActionBased} whereas \textsf{R6} is \textsf{StateBased}. \textsf{R1} states that a doctor can only consult his own patients' files. This rule is identified by $\mathsf{r_1}$, and states that the action \textsf{consult}, whose subject is \textsf{doctor} is valid only if the conjuncted context \textsf{fileIsPrivate \& patientFileToDoctor} holds. \textsf{R5} stipulates that a doctor has to delete his patients' files within two years. 
Rules \textsf{R2} -- \textsf{R4} specify a scenario of dependent rules: if \textsf{R2} is violated, then the obligation \textsf{R3} and the prohibition \textsf{R4} become active. This demonstrates \SAR ability to deal with predefined policy violations. 
Furthermore, \SAR can go one step further. Consider for example that a patient's file is not deleted for medical reasons, because the patient's condition requires further follow-up visits after this two-years period. Security experts can dynamically update the security policy with a new rule that takes this case into account: \textsf{obligation($r_7$, doctor, submit, justificationReport, violation\_$r_5$, delay(7d))} forces a doctor who has violated \textsf{R5} to submit a justification report within one week after this two-years period. 
This rule can be added and enforced into the system at runtime.

%A policy needs to satisfy the following requirements: abstraction and expressiveness. A security policy consists of a set of security rules specifying what a subject is allowed, prohibited and/or obliged to do on system resources. The concrete policy entities are {\it subject} denoting active entities in the system (users). The abstract policy entities are {\it role}, {\it action}, {\it activity} and {\it context}, denoting a set of subjects, an action, a set of actions and a set of state conditions respectively. Security policy rules are specified over these abstract entities. %to simplify policy specification, interpretation and reuse. 



%Figure \ref{figure_rules} shows the policy language metamodel: Every security rule has a unique identifier, a subject and an activation context defining when the rule is effective. The subject of a security rule is either a reference to a {\it declared} role or the special role {\it any}, denoted by \_ in the language's concrete syntax. A rule could be either action\_based, i.e. it specifies a required action (or activity) or state\_based, i.e. it specifies a required context. An obligation has, as opposed to a prohibition/permission, a violation context (a deadline). A deadline provides an obligation subject a period of time to fulfill his obligation before the obligation is considered violated. %Note that a context is an abstract concept, its definition is presented later in Section~\ref{}.

%\comments{To illustrate the policy language's concrete syntax, consider the following requirements corresponding to the security requirements of an Auction Management Sales System (ASMS): (1) Only users can update the information of their accounts,
%(2) To avoid spam, each user may not post more than 50 comments during a sale session, (3) When a user posts a comment including a word specified in a blacklist, then the moderator has to delete the post, (4) When a user's account is negative, then the user has to make the account positive again within one week, (5) a moderator can take the action to delete a comment at any time. These requirements are specified as follows:
%
%\comments{
%\begin{figure}
%\center
%\includegraphics[width=8cm]{example_policy.pdf} 
%\caption{Policy Rule Examples}
%\label{figure_example_policy}
%\end{figure}
%}
%
%\srsil{$perm(r_1,user, update\_account\_info, account, personal\_account)$,}
%{$proh(r_2,user, post\_comment, sale,exceeded\_50\_comments)$,}
%{$oblig(r_3,moderator,delete\_comment,comment,$}
%{$comment\_contains\_blacklisted\_word,delay(1h))$,}
%{$oblig_s(r_4,user,\neg has\_negative\_balance,has\_negative\_balance,delay(7d)) $,}
%{$perm(r_5,moderator,delete\_comment,\_,true) $.}
%}
%
%To illustrate the policy language's concrete syntax, consider the following requirements: (1) A doctor may only consult the private files of his patients, (2) after a doctor creates a private patient file, the doctor is obliged to delete the file within two years. Throughout the paper, these two rules are used to illustrate our approach to link policies to different target systems. However, several other requirements may be defined such as: (3) Upon the disclosure of a patient's information to a 3rd party, the patient has to be notified within one week, or (4) a doctor may not delete his patient public files.
%
%\crfil{$perm(r_1,doctor, consult, file, personal\_doctor)$,}
%{$oblig(r_2,doctor, delete\_file, file,file\_creation, delay(2y))$,}
%{$oblig(r_3,organization,notify,patient,$}
%{$patient\_information\_disclosure,delay(7d))$,}
%%{$oblig_s(r_4,organization,encrypted\_file,private\_file,true) $,}
%{$proh(r_4,doctor,delete\_file,file,public\_file) $.}
%
%
%\noindent In the rules above, the context {\it delay(UC)} is a context that holds after the elapse of {\it U} time units {\it C} after the activation of the security rule. %The context {\it true} is a context that always holds. 
%The context language is described by the metamodel in Figure~\ref{figure_context}. %Note that a context expression is an abstract concept, its definition is presented later in Section~\ref{}. %In the metamodel, 
%%{\it True} ({\it False}) denotes a context that always (never) holds. A basic context is defined using {\it hold} rules as discussed in Section~\ref{}.

%\begin{figure}
%\center
%\includegraphics[width=10cm]{context.pdf} 
%\caption{Context Language}
%\label{figure_context}
%\end{figure}
%
%\paragraph{Sanction Policies} It is necessary to compensate obligation violation. For example, we may specify that if a doctor violates the obligation $r_2$ to delete a patient's file then the doctor has to submit a {\it violation\_justification\_report} within one week as follows. 
%
%\crsl{$oblig(r_5,doctor,submit,violation\_justification\_report,violation\_r_2,true)$.}
%
%\noindent Note that it is also possible to activate/deactivate authorization rules, or activate/cancel obligations in response to obligation violation/fulfillment.
%
%The policy language is specified abstractly to simplify its specification, interpretation and reuse. The main abstract policy entities are role, action and context. In the following, we show how the concrete entities of target applications are linked to these abstract entities.

%\comments{
%To link the policy to a specific target (application domain), the concrete entities of the target are assigned to abstract policy entities using two sets of assignment rules, namely static and contextual assignment rules. In the following, we first discuss assignments for Java-based systems, then we show how the same methodology can be similarly applied for component-based systems to demonstrate the generality of our approach. 
%}

%\subsection{Role Declaration}
%A role declaration define a relationship between the classes of the target application to policy {\it roles}. A policy role denotes a set of policy subjects. 
%
%
%
%\subsubsection{Java Role Declaration}
%\label{section_role_declaration_java}
%
%A Java role declaration specifies that the {\it instances} of the declaration's {\it class} are assigned the declaration's {\it role}. For example, consider the following assignment\footnote{We use the symbol * instead of fully qualified names for convenience.}.
%
%\begin{center}
%%\small
%\begin{tabular}{l l}
%{\bf Role\_Name} {\it doctor} &    \\
%{\bf Class\_Name} {\it com.*.person.Doctor}&  \\
%{\bf Relevant\_Attributes} {\it ArrayList$<$String$>$ : patient\_names} &
%\end{tabular}
%\end{center}
%
%\noindent This role assignment specifies that every {\it instance} of the class {\it Doctor} is assigned the role of {\it doctor}. The attribute {\it patient\_names} of {\it Doctor} is also declared as being relevant to the policy. 
%
%\comments{
%\subsubsection{Components Role Declaration}
%\label{section_role_declaration_comp}
%}
%
%\subsection{Action Declaration}
%\label{section_action_declaration}
%An action declaration defines a relationship between the application's behavioral elements such as method calls and policy actions. 
 %
%\subsubsection{Java Action Declarations}
%\label{section_action_declaration_java}
%A Java action declaration specifies that the {\it ordered} execution of some (sequence of) {\it method call(s)} correspond to some {\it policy action}. Java methods may be assigned identifiers to simplify their use in contextual assignments presented in the following section. 

%\begin{center}
%%\small
%\begin{tabular}{l p{0.2cm} l}
%{\bf Action\_Name} &&{\it delete\_file}     \\
%{\bf Method\_IDs} &&{\it deleteService, deleteDB}  \\
%{\bf Method\_Signatures} &&*.Service.deleteFile(int,String,int),\\
%&& *.DB.deleteFile(File)		
%\end{tabular}
%\end{center}

%\noindent The previous proposition states that the method call {\it Service.deleteFile} followed by the method call {\it DB.deleteFile} corresponds to taking the policy action {\it delete\_file}. The {\it Method\_IDs} part specifies identifiers for methods appearing in the {\it Method\_\-Signa\-tures} part of the action declaration.


%\comments{
%
%\subsubsection{Components Action Declaration}
%\label{section_action_declaration_comp}
%
%
%Java includes the abstract concepts of classes, attributes and methods as well as their concrete counterparts, e.g. instances and fields. Our static mapping for Java is shown in Figure~\ref{figure_declarations}. It shows two types of declarations: {\it role} and {\it action} declarations. %Role declarations map classes of the target to roles in the policy. Action declarations on the other hand links (sequences of) methods to policy actions. 
%A role declaration states that the {\it instances} of the declaration's {\it class} should be assigned the declaration's {\it role}. A role declaration further allows the optional specification of a set of the class attributes as being {\it policy-relevant}. We discuss the importance of declaring policy-relevant attributes later in Section~\ref{section_Java_assignments}. 
%
%
%An action declaration specifies that the {\it ordered} execution of some (sequence of) {\it method call(s)} correspond to some {\it policy action}. Java methods may be assigned identifiers to simplify their use in dynamic assignments as will be shown in the following section. 


 
%\begin{figure}
%\center
%\includegraphics[width=10cm]{declarations.pdf} 
%\caption{Static Assignments: Role and Action Declarations}
%\label{figure_declarations}
%\end{figure}
%
%For example, consider the following assignments\footnote{We use the symbol * instead of fully qualified names for convenience.}.
%
%\begin{center}
%%\small
%\begin{tabular}{l l}
%{\bf Role\_Name} {\it user} &    \\
%{\bf Class\_Name} {\it com.*.person.User}&  \\
%{\bf Relevant\_Attributes} {\it UserAccount : userAccount} &
%\end{tabular}
%\end{center}
%
%\begin{center}
%%\small
%\begin{tabular}{l p{0.2cm} l}
%{\bf Action\_Name} &&{\it delete\_comment}     \\
%{\bf Method\_IDs} &&{\it deleteServer, deleteSale}  \\
%{\bf Method\_Signatures} &&*.CommentService.deleteComment(int,String,int),\\
%&& *.Sale.deleteComment(Comment)		
%\end{tabular}
%\end{center}
%
%\noindent The previous role declaration states that instances of the class {\it User} should be assigned the role of {\it user}. It further specifies that the attribute {\it userAccount} is a relevant to the security policy. The second proposition states that the consecutive execution of the methods {\it CommentService.deleteComment} and {\it Sale.deleteComment} corresponds to taking the policy action {\it delete\_account}. The {\it Method\_IDs} part specifies identifiers for the methods appearing in the {\it Method\_\-Signa\-tures} part of the action declaration.
%
%}
%explanation
